Roll, Roll, Roll your Root:A Comprehensive Analysis of the First Ever DNSSEC Root KSK Rollover

The DNS Security Extensions (DNSSEC) add authenticity and integrity to the naming system of the Internet. Resolvers that validate information in the DNS need to know the cryptographic public key used to sign the root zone of the DNS. Eight years after its introduction and one year after the originally scheduled date, this key was replaced by ICANN for the first time in October 2018. ICANN considered this event, called a rollover, "an overwhelming success" and during the rollover they detected "no significant outages". In this paper, we independently follow the process of the rollover starting from the events that led to its postponement in 2017 until the removal of the old key in 2019. We collected data from multiple vantage points in the DNS ecosystem for the entire duration of the rollover process. Using this data, we study key events of the rollover. These events include telemetry signals that led to the rollover being postponed, a near real-time view of the actual rollover in resolvers and a significant increase in queries to the root of the DNS once the old key was revoked. Our analysis contributes significantly to identifying the causes of challenges observed during the rollover. We show that while from an end-user perspective, the roll indeed passed without major problems, there are many opportunities for improvement and important lessons to be learned from events that occurred over the entire duration of the rollover. Based on these lessons, we propose improvements to the process for future rollovers

A Cooperative Game with Applications to Computer Networks

This paper extends our previous results [3]. Cheriton implemented this strategy in the V operating system, employing the uniform distribution [2]. The uniform distribution is intuitively appealing, and, at first glance, appears optimal. The optimal distribution depends on the number of recipients n, the number of buffers b

Flow Control for Limited Buffer Multicast

This paper analyzes a multi-round flow control algorithm that attempts to minimize the time required to multicast a message to a group of recipients and receive responses directly from each group member. Such a flow control algorithm may be necessary because the flurry of responses to the multicast can overflow the buffer space of the process that issued the multicast. The condition that each recipient directly respond to the multicast prevents the use of reliable multicast protocols based on software combining trees or negative-acknowledgements. The flow control algorithm analyzed here directs the responding processes to hold their responses for some period of time, called the backoff time, before sending them to the originator. The backoff time depends on the number of recipients that will respond, the originator's available buffer space and buffer service time distribution, and the number of times that the originator is willing to retransmit its message. This paper develops an appro..